RDS Proxy, Amazon Kendra, Amazon CodeGuruの紹介 #cmregrowth #reinvent

re:Invent2019で発表されたUPDATEのうち、個人的に気になった RDS Proxy, Amazon Kendra, Amazon CodeGuruをre:Growth 2019 OSAKAにてご紹介させていただきました。その登壇内容です。

AWS re:Invent 2019

#レポート

#イベント

#RDS Proxy

#Amazon RDS

#Amazon Kendra

かずえ

2019.12.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

弊社はre:Invent振り返り勉強会 re:Growth 2019 OSAKA を開催いたしました。お越し下さった皆々様、ありがとうございました！！

私は、個人的に気になったRDS Proxy, Amazon Kendra, Amazon CodeGuruをご紹介させていただきました。以下登壇内容です。

注意点：3サービスともプレビューです

今後サービス内容が変わる可能性があります
突然サービス停止する可能性があります
「やってみた」情報を開示することはNGです

詳しくは以下ブログエントリをご覧ください。

[AWS] re:Invent 前に理解しておくべきベータ/プレビューサービスの扱いについて #reinvent

RDS Proxy

問題点 Lambda - RDSはアンチパターン

その理由として、これまで以下のようなことが挙げられていました。

接続処理（コネクションプーリング難しい）の問題
同時接続数の問題
IPアドレス枯渇問題
コールドスタートの問題

このうち、IPアドレス枯渇問題は9月にリリースされたHyperplane ENIによって改善されました。また、コールドスタートの問題も、Hyperplane ENIと、re:Invent中に発表された Provisioned Concurrencyによって改善されました。

接続処理問題、同時接続数の問題が残っています。

接続処理もしくは同時接続数の問題

一般的にLambdaでコネクションプーリング（リクエスト間でDB接続を共有する）を使うのは困難でした。これによってDB接続処理が多発し

DBリソースを消費
処理遅延
同時接続数上限に引っかかりやすい→エラー

ということが発生します。ですのでアンチパターン、と言われてきました。 (要件次第では問題にならない場合もあります。ですのであらゆる場面でアンチパターンというわけではありません。）

この部分を改善するサービスが、今回発表されたRDS Proxyです。

RDS Proxy

これまで

これから（RDS Proxyあり構成）

Lambda（アプリ）とRDSとの間にRDS Proxyを設置する構成が取れるようになりました。こうすることで面倒な実装なしでコネクションプーリングを実現することができ、先ほどご紹介した接続処理にまつわる問題を緩和することができます。また、RDS Proxyはプロビジョニング、パッチ当て等も不要なマネージドサービスです(NAT Gatewayとかみたいなイメージ)。ですので運用負荷があがることもありません。アプリ側(コード)も接続エンドポイントをRDSのものからProxyのものに変えるだけで利用可能です。簡単！

効果

以下は先週開催されたServerless Night Osakaにて、AWSのSAの方が実施されたRDS Proxyのデモ結果です。同じワークロードを、RDS Proxyない構成とある構成どちらでも試してみて、DBの同時接続数がどう変わるかというのを調べた結果です。如実に効果が出ています！

というわけで、RDS Proxyのおかげで今後は Lambda - RDSの構成を取れる要件の幅がより拡がりそうです！

Kendra

Kendraはざっくりいうと企業向け検索サービスです。ではまず、検索に現在どのような問題があるのか見てみましょう。

問題点: 検索は難しい

調査

以下のような調査結果があるそうです。

従業員はその労働時間の20％を情報を探すのに費やしている
仕事をするにあたり必要な情報を44%しか見つけることができていない
→ このように、検索する（=必要な情報を探す）ことに苦労している結果、従業員一人当たり年間5,700ドル(約62万円)の損失が発生している

原因は？

どこで検索したら良いかわからない
データソースが分散している
キーワード検索
単にキーワードに合致した文書を拾っているだけなので、ヒットした情報が欲しいものとは限らない
インデックス化しにくい
非構造化データ、様々な形式のフォーマット、、

Amazon Kendra

機械学習による高精度エンタープライズ向け検索サービス

どのような特長があるか見ていきましょう。

あらゆるデータソースと接続し、それらを対象にまとめて検索できる

先ほどお話しした「どこで検索したら良いかわからない」という問題は、データソースを全てKendraに食わせれば、Kendraからの検索=全ソースに対しての検索という状況を実現できます。Kendraは上記ソースとの接続をコンソール上で簡単に設定できるように対応予定です。現段階ではS3、RDS、Sharepoint Onlineのみの対応です。（なお、ここに挙がっていないソースでもコードを書けば接続可能です）

対話的な検索ができる（質問を理解している/文書内容も理解している）

Kendraは機械学習によって質問内容を理解することができます。また検索対象となる文書群の内容も理解しています。ですので、より対話的な、人に尋ねると同じような方法で検索することができます。対してKendraは質問内容を理解していますので、（キーワード検索に比べて）より直接的な回答を返してくれます。

以下はユーザーがKendraを使うUI例です。一番上の「Where is the it supprt in kumo?(kumoにはITサポートデスクがどこにありますか？)」がユーザーの行なった検索です。(kumoはamazonオフィスが入っているビル名らしいです)

Kendraはこの質問に対して端的に「1st floor(一階です)」と答えることができます。これによりユーザーは検索に費やす時間（検索結果から自身の知りたい情報を探す時間）を大幅に減らすことができます。（後ろにその情報元文書のリンク、関連FAQなどが続きますので、関連する情報をもっと知りたい場合にも役立ちます）